Methods for rule-based dynamic resource adjustment for upstream and downstream processing units in response to an intermediate processing unit event

ABSTRACT

A method dynamically adjusts the resources available to a processing unit of a distributed computer process executing on a multi-node computer system. The resources for the processing unit are adjusted based on the data other processing units handle or the execution path of code in an upstream or downstream processing unit in the distributed process or application.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is a continuation of U.S. Ser. No. 12/357,984filed on Jan. 22, 2009, which is incorporated herein by reference.

BACKGROUND

1. Technical Field

The disclosure and claims herein generally relate to computer processallocation and distribution on a multi-node computer system, and morespecifically relate to dynamic resource adjustment of a distributedcomputer process on a multi-node computer system.

2. Background Art

Supercomputers and other multi-node computer systems continue to bedeveloped to tackle sophisticated computing jobs. One type of multi-nodecomputer system is a massively parallel computer system. A family ofsuch massively parallel computers is being developed by InternationalBusiness Machines Corporation (IBM) under the name Blue Gene. The BlueGene/L system is a high density, scalable system in which the currentmaximum number of compute nodes is 65,536. The Blue Gene/L node consistsof a single ASIC (application specific integrated circuit) with 2 CPUsand memory. The full computer is housed in 64 racks or cabinets with 32node boards in each rack.

Computer systems such as Blue Gene have a large number of nodes, eachwith its own processor and local memory. The nodes are connected withseveral communication networks. One communication network connects thenodes in a logical tree network. In the logical tree network, the nodesare connected to an input-output (I/O) node at the top of the tree. InBlue Gene, there are 2 compute nodes per node card with 2 processorseach. A node board holds 16 node cards and each rack holds 32 nodeboards. A node board has slots to hold 2 I/O cards that each have 2 I/Onodes.

A distributed process is a computer application or program or portion ofa computer program where one or more portions of the distributed processare allocated to different hardware resources. In a distributed processacross many nodes a traditional program can be thought of as anexecution of “processing units” that are dispersed and executed overmultiple nodes. In this type of distributed environment, one is oftenunaware of what node a given processing unit is running Processing unitsare often detached from one another and may be unaware of where otherprocessing units are running. In this type of distributed environment,adjusting priorities of processing units or adjusting compute resourcesis not a simple task. Simply moving compute resources around from nodeto node as a reaction to the current needs or current job priorities issimply inadequate. For example, in a distributed environment a piece ofcode or a processing unit may be executed on behalf of many differentapplications or jobs. In some cases, these processing units will havehigher priority than others but in many cases they will not.Furthermore, an application may or may not have a consistent prioritythroughout its execution. In some cases, the priority of the applicationmay be more appropriately determined by the data that it is handling orchanges in the means and mechanisms needed to carry out the entire job.

Without an efficient way to allocate resources to processing units in adistributed computer system environment, complex computer systems willcontinue to suffer from reduced performance and increased powerconsumption.

BRIEF SUMMARY

The specification and claims herein are directed to dynamicallyadjusting the resources available to a processing unit of a distributedcomputer process executing on a multi-node computer system. Theresources for the processing unit are adjusted based on the data otherprocessing units handle or the execution path of code in an upstream ordownstream processing unit in the distributed process or application.

The description and examples herein are directed to a massively parallelcomputer system such as the Blue Gene architecture, but the claimsherein expressly extend to other parallel computer systems with multipleprocessors arranged in a network structure.

The foregoing and other features and advantages will be apparent fromthe following more particular description, and as illustrated in theaccompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS

The disclosure will be described in conjunction with the appendeddrawings, where like designations denote like elements, and:

FIG. 1 is a block diagram of a massively parallel computer system;

FIG. 2 is a block diagram of a compute node in a massively parallelcomputer system;

FIG. 3 shows a block diagram of a sample rules registry;

FIG. 4 shows examples of data event rules stored in the rules registry;

FIG. 5 shows examples of code point rules stored in the rules registry;

FIG. 6 shows a block diagram to illustrate an example of dynamicresource adjustment of a distributed computer process on a multi-nodecomputer system;

FIG. 7 is a method flow diagram of dynamic resource adjustment of adistributed computer process on a multi-node computer system; and

FIG. 8 is a method flow diagram that illustrates the resource controllerperforming dynamic resource adjustment of a distributed computer processon a multi-node computer system.

DETAILED DESCRIPTION

The specification and claims herein are directed to dynamicallyadjusting the resources available to a processing unit of a distributedcomputer process executing on a multi-node computer system. Theresources for the processing unit are adjusted based on the data otherprocessing units handle or the execution path of code in an upstream ordownstream processing unit in the distributed process or application.The examples herein will be described with respect to the Blue Gene/Lmassively parallel computer developed by International Business MachinesCorporation (IBM).

FIG. 1 shows a block diagram that represents a massively parallelcomputer system 100 such as the Blue Gene/L computer system. The BlueGene/L system is a scalable system in which the maximum number ofcompute nodes is 65,536. Each node 110 has an application specificintegrated circuit (ASIC) 112, also called a Blue Gene/L compute chip112. The compute chip incorporates two processors or central processorunits (CPUs) and is mounted on a node daughter card 114. The node alsotypically has 512 megabytes of local memory (not shown). A node board120 accommodates 32 node daughter cards 114 each having a node 110.Thus, each node board has 32 nodes, with 2 processors for each node, andthe associated memory for each processor. A rack 130 is a housing thatcontains 32 node boards 120. Each of the node boards 120 connect into amidplane printed circuit board with a midplane connector 134. Themidplane circuit board is inside the rack and not shown in FIG. 1. Themidplane 132 includes all the node boards connected to the midplaneprinted circuit board and the nodes in the node boards. The full BlueGene/L computer system would be housed in 64 racks 130 or cabinets with32 node boards 120 in each. The full system would then have 65,536 nodesand 131,072 CPUs (64 racks×32 node boards×32 nodes×2 CPUs).

The Blue Gene/L computer system structure can be described as a computenode core with an I/O node surface, where each I/O node has an I/Oprocessor connected to the service node 140. The service node 140 isconnected to the nodes thorough a control system network 150 and afunctional network 152. The functional network is a gigabit Ethernetnetwork connected to an I/O processor (or Blue Gene/L link chip) in theI/O node 170 located on a node board 120 that handles communication fromthe service node 160 to a number of nodes. The Blue Gene/L system hasone or more I/O nodes 170 connected to the node board 120. The I/Oprocessors can be configured to communicate with 8, 32 or 64 nodes. Theservice node 140 uses the control system network 150 to controlconnectivity by communicating to link cards on the compute nodes. Theconnections to the I/O nodes are similar to the connections to thecompute node except the I/O nodes are not connected to the torus networkthat interconnects the compute nodes.

Again referring to FIG. 1, the computer system 100 includes a servicenode 140 that handles the loading of the nodes with software andcontrols the operation of the whole system. The service node 140 istypically a mini computer system such as an IBM PSERIES server runningLinux with a control console (not shown). The service node 140 isconnected to the racks 130 of compute nodes 110 with a control systemnetwork 150 and a functional network 152. The control system networkprovides control, test, and bring-up infrastructure for the Blue Gene/Lsystem. The control system network 150 includes various networkinterfaces that provide the necessary communication for the massivelyparallel computer system. The service node 140 is also connected to oneor more front-end computers 148.

The service node 140 communicates through the control system network 150dedicated to system management. The control system network 150 includesa private 100-Mb/s Ethernet connected to an Ido chip 180 located on anode board 120 that handles communication from the service node 160 to anumber of nodes. This network is sometime referred to as the JTAGnetwork since it communicates using the JTAG protocol. All control,test, and bring-up of the compute nodes 110 on the node board 120 isgoverned through the JTAG port communicating with the service node.

The service node includes a database 138 (DB2) for local data storage.The service node further includes a control system 142 to control theoperation of the multi-node computer system 100. The service node 140also includes a resource controller 143 for allocating and schedulingwork processes and data placement on the compute nodes. The resourcecontroller 143 includes a rules registry 144 and an optimizing agent145. These are described further below.

FIG. 2 illustrates a block diagram of an exemplary compute node 110 asintroduced above. FIG. 2 also represents a block diagram for an I/Onode, which has the same overall structure as the compute node. Anotable difference between the compute node and the I/O nodes is thatthe Ethernet adapter 226 is connected to the control system on the I/Onode but is not used in the compute node. The compute node 110 of FIG. 2includes a plurality of computer processors 210, each with an arithmeticlogic unit (ALU) 211 and a memory management unit (MMU) 212. Theprocessors 210 are connected to random access memory (RAM) 214 through ahigh-speed memory bus 215. Also connected to the high-speed memory bus215 is a bus adapter 217. The bus adapter 217 connects to an extensionbus 218 that connects to other components of the compute node.

Again referring to FIG. 2, stored in RAM 214 is a class routing table221, a processing unit (or application) 222 that includes an eventdetection mechanism 223, and an operating system kernel 224. The classrouting table 221 stores data for routing data packets on the collectivenetwork or tree network as described more fully below. The processingunit 222 is a user software application, process or job that is loadedon the node by the control system to perform a designated task. Theapplication program typically runs in parallel with application programsrunning on adjacent nodes. As used herein, processing unit means anapplication or job or a portion of the application or job executing inone or more nodes of the system. The processing unit includes an eventdetection mechanism 223. The event detection mechanism is used tomonitor events stored in a rules registry as described below. Theoperating system kernel 224 is a module of computer program instructionsand routines for an application program to access to other resources ofthe compute node. The quantity and complexity of tasks to be performedby an operating system on a compute node in a massively parallelcomputer are typically smaller and less complex than those of anoperating system on a typical stand alone computer. The operating systemmay therefore be quite lightweight by comparison with operating systemsof general purpose computers, a pared down version as it were, or anoperating system developed specifically for operations on a particularmassively parallel computer.

The compute node 110 of FIG. 2 includes several communications adapters226, 228, 230, 232 for implementing data communications with other nodesof a massively parallel computer. Such data communications may becarried out serially through RS-232 connections, through external busessuch as USB, through data communications networks such as IP networks,and in other ways as will occur to those of skill in the art.Communications adapters implement the hardware level of datacommunications through which one computer sends data communications toanother computer, directly or through a network.

The data communications adapters in the example of FIG. 2 include aGigabit Ethernet adapter 226 that couples example I/O node 110 for datacommunications to a Gigabit Ethernet on the Functional network 152. InBlue Gene, this communication link is only used on I/O nodes and is notconnected on the compute nodes. Gigabit Ethernet is a networktransmission standard, defined in the IEEE 802.3 standard, that providesa data rate of 1 billion bits per second (one gigabit). Gigabit Ethernetis a variant of Ethernet that operates over multimode fiber optic cable,single mode fiber optic cable, or unshielded twisted pair.

The data communications adapters in the example of FIG. 2 include a JTAGSlave circuit 228 that couples the compute node 110 for datacommunications to a JTAG Master circuit over a JTAG network or controlsystem network 150. JTAG is the usual name used for the IEEE 1149.1standard entitled Standard Test Access Port and Boundary-ScanArchitecture for test access ports used for testing printed circuitboards using boundary scan. JTAG boundary scans through JTAG Slave 228may efficiently configure processor registers and memory in compute node110.

The data communications adapters in the example of FIG. 2 include aPoint To Point Network Adapter 230 that couples the compute node 110 fordata communications to a network 238. In Blue Gene, the Point To PointNetwork is typically configured as a three-dimensional torus or mesh.Point To Point Adapter 230 provides data communications in sixdirections on three communications axes, x, y, and z, through sixbidirectional links 238: x+, x−, y+, y−, z+, and z−. The torus networklogically connects the compute nodes in a lattice like structure thatallows each compute node 110 to communicate with its closest 6neighbors.

The data communications adapters in the example of FIG. 2 include acollective network or tree network adapter 232 that couples the computenode 110 for data communications to a network 240 configured as a binarytree. This network is also sometimes referred to as the collectivenetwork. Collective network adapter 232 provides data communicationsthrough three bidirectional links: two links to children nodes and onelink to a parent node (not shown). The collective network adapter 232 ofeach node has additional hardware to support operations on thecollective network.

Again referring to FIG. 2, the collective network 240 extends over thecompute nodes of the entire Blue Gene machine, allowing data to be sentfrom any node to all others (broadcast), or a subset of nodes. Each nodetypically has three links, with one or two links to a child node and athird connected to a parent node. Arithmetic and logical hardware isbuilt into the collective network to support integer reductionoperations including min, max, sum, bitwise logical OR, bitwise logicalAND, and bitwise logical XOR. The collective network is also used forglobal broadcast of data, rather than transmitting it around in rings onthe torus network.

The specification and claims herein are directed to dynamicallyadjusting the resources available to a processing unit. The resourcecontroller 143 (FIG. 1) adjusts the resources for a processing unitbased on the data another processing unit handles or the code thatexecutes in an upstream or downstream processing unit in the distributedprocess or application. Data that is being consumed or produced by agiven processing unit is referred herein as data of the processing unitor data handled by the processing unit. The processing unit data isanalyzed to be used to signal a shift in resources of upstream anddownstream processing units. Alternatively, the resource controllerdynamically adjusts compute resources based off reaching specificexecution points in a processing unit. In this scenario, a processingunit reaching a specific point in execution would trigger the resourcecontroller to automate the movement of resources. This could beadvantageous where a processing unit normally takes a long time to run aprocess or method that has downstream repercussions. For example, ifprocessing unit A takes a long time for a process B, the resourcecontroller could affect job workflow of downstream compute nodes byslowing down processing units upstream of processing unit A and likewiseadjust processing units downstream. The resource controller can adjustthe resources downstream because they will not need to do as muchsubsequent processing right away, and it might adjust resources upstreamto slow down future work it might do, both resulting in more resourcesavailable to other jobs or other parts of the application. This type ofadjusting of resources could free up resources for other runningprocessing units on different nodes.

As described above, the resource controller 143 (FIG. 1) adjusts theresources for a processing unit based on the data another processingunit handles or the code that executes in an upstream or downstreamprocessing unit. As used herein, compute resources means hardwareresources such as central processing unit (CPU) resources, memory,network resource, or virtual allocation of CPU, memory and networkresources. Compute resources could also be software resources availableto a node. The resource controller adjusts resources to a processingunit in different ways depending on the system architecture. Theresource controller can adjust the compute resources by moving otherprocesses on the same node to other nodes to free up the node'sresources for the remaining processing unit. In a distributed computingsystem with virtual resources, the resource controller can dedicate moresystem resources by increasing the virtual allocation of CPU, memory, ornetwork bandwidth as described in the example below.

FIG. 3 shows a block diagram that represents one specific implementationof the rules registry 144 introduced in FIG. 1 above. The rules registry144 includes several different types of rules that are used by theresource controller to determine how to handle certain events todynamically adjust computer resources of a distributed computer processon a multi-node computer system. The rules registry 144 shown in FIG. 3includes data event rules 312, code point rules 314 and other rules 316.The data event rules 312 and code point event rules 314 are describedfurther below. The other rules 316 represent other possible rules thatcould be used to allocate resources as described and claimed herein. Theevents in the rules registry could be detected by various means. Thesevarious means include an event detection mechanism 223 as shown in FIG.2. For example, code point events could be detected by the eventdetection mechanism like a debugger that tracks the execution of thecode. Alternatively, the event detection mechanism 223 could be codethat is generated and placed at the code point that notifies theresource controller of the detected event. Thus a user or software toolidentifies a code point associated with a rule, and generates code forthe event detection mechanism that is inserted into the executable ofthe processing unit (PU) at the appropriate code point. Similarly, forinput-driven rules, the event detection mechanism could monitor dataflowing in and out of the processing unit. Alternatively, the processingunits typically function within an execution control system or frameworkwhich provides each PU with the ability to know when data has been sentto it. In this case the event detection mechanism could be additionalcode that is generated and placed into the executable of any processingunit that had an input rule defined. This code would be placed at thepoint of the PU that handles data input and output to detect theoccurrence of the data event.

FIG. 4 illustrates some examples of data event rules 312. The data eventrules have an event 410 and a corresponding action 412. Each eventpreferably specifies a processing unit identification (ID) and acondition that pertains to data. Each action 412 preferably specifies anode ID and an action to adjust compute resources, such as increase CPUor memory allocation. For example, the first example event 414 is forprocessing unit number 620 and the condition is a data quantity ofgreater than 10,000 records. The action 416 for this data event ruleincreases CPU by 500% and memory by 200% on processing unit 624, anddecreases CPU by 200% on processing unit 614. The second event 418 isfor a specific data type. Here an event is detected when the type ofdata handled by processing unit 624 is video (or a specific type ofvideo). Similarly, FIG. 5 illustrates code point rules 314. Code pointrules also have an event 510 and an action 512 that relate to a specificprocessing unit. The data in FIGS. 4 and 5 will be used in the exampledescribed with reference to FIG. 6.

An example will now be described with reference to FIG. 6. The resourcecontroller 143 interprets rules in the rules registry 144 to determinehow to dynamically control the allocation of compute resources such asfor processing units on the compute nodes 110. The rules registry 144has a number of rules as described above. These rules may be set by auser 610 or by an optimizing agent 145. The optimizing agent 145 issoftware that can monitor the performance of the resource controller andcreate rules similar to the rules described above. Processing unit 612is shown in FIG. 6 to represent that the resource controller 143 isnotified by processing units of events according to the rules registry144. When the resource controller receives notification of a rulesevent, it controls allocation of compute resources as dictated by therule action associated with the event as described above. Copies of therules registry or portions of the rules registry may also be located inRAM 214 on a node 110 as shown in FIG. 2.

Again referring to the Example of FIG. 6, a distributed application isrepresented by a series of processing units (including 614, 620, 624)that are connected by arrows 618 that represent a process flow or a flowof data. The arrows show the process flow as a path from one processingunit to the next that make up the distributed process. The firstprocessing unit 614 in the process flow is located in Node1 616. Theprocess then continues as indicated by the arrow 618 to the otherprocessing units. In our example, we assume that processing unit 620encounters an event 414 (FIG. 4) and notifies the resource controller143. The resource controller takes the actions 416 (FIG. 4) as indicatedin the rules registry to increase the CPU by 500% and increase memory by200% on the downstream processing unit 624, and decrease the CPU by 200%on upstream processing unit 614, where a downstream processing unit (PU)is a PU that is subsequent in the process flow or data flow, and anupstream PU is a PU that is earlier in the process flow or data flow.

FIG. 7 shows a method 700 for dynamic resource adjustment of adistributed computer process on a multi-node computer system. The stepsin method 700 are preferably performed by a resource scheduler 143 inthe service node 140. The first step is to monitor processing unitevents (step 710). If a detected event is an data event (step 712=yes),then analyze the data handled by the processing unit (step 716) anddetermine if the data meets the event criteria (step 718). If the datadoes not meet the event criteria (step 718=no) then return to step 710.If the data does meet the event criteria (step 718=yes) then notify theresource controller of the event (step 720). If the detected event isnot an data event (step 712=no) then check for a code event (step 714).If the detected event is not a code point event (step 714=no), thenreturn to step 710. If the detected event is a code point event (step714=yes), then notify the resource controller of the event (step 720).The method is then done.

FIG. 8 shows a method 800 performing dynamic resource adjustment of adistributed computer process on a multi-node computer system. The stepsin method 800 are preferably performed by a resource scheduler 143 inthe service node 140 when notified by a resource controller of adetected event. The first step is to look up the actions in the resourceregistry for the event (step 810). Next, determine the affectedprocessing units (step 820). Next, lookup the nodes hosting the affectedprocessing units (step 830) and reallocate the resources on the nodes ofthe processing units per the actions indicated in the rules registry(step 840). Where necessary, move processing units to a new node toreallocate the resources for a processing unit (step 850). The method isthen done.

An apparatus and method is described herein directed to dynamicallyadjusting the resources available to a processing unit of a distributedcomputer process executing on a multi-node computer system. One skilledin the art will appreciate that many variations are possible within thescope of the claims. Thus, while the disclosure has been particularlyshown and described above, it will be understood by those skilled in theart that these and other changes in form and details may be made thereinwithout departing from the spirit and scope of the claims.

The invention claimed is:
 1. A computer-implemented method forallocating computer resources on a multi-node computer system, themethod comprising the steps of: monitoring processing unit events withan event detection mechanism; analyzing input data used by a firstprocessing unit to determine if a data event meets an event criteria ina rules registry; notifying a resource controller when the data eventmeets the event criteria; notifying the resource controller when a codepoint event occurs; and the resource controller reallocating computeresources for a second processing unit and a third processing unit whenthe code point event occurs and when the data event meets the eventcriteria, wherein the second processing unit is located on a computenode downstream from the first processing unit in a distributed system,and the third processing unit is located on a compute node upstream fromthe first processing unit, and wherein, upon detection of the code pointevent occurring in the first processing unit, or upon detection of thedata event occurring in the first processing unit and meeting the eventcriteria, the resource controller reallocates the compute resources byincreasing compute resources for the second processing unit anddecreasing compute resources for the third processing unit.
 2. Thecomputer-implemented method of claim 1 wherein the step of reallocatingcompute resources comprises the steps of: looking up an action in therules registry for a detected event; determining an affected processingunit from the rules registry; looking up a node hosting the affectedprocessing unit; and reallocating resources on the node hosting theaffected processing unit per actions indicated in the rules registry. 3.The computer-implemented method of claim 2 further comprising the stepof moving processing units to a new node to adjust compute resources onthe node hosting the affected processing unit.
 4. Thecomputer-implemented method of claim 1 wherein compute resourcesindicated in the rules registry comprise computer processing unit,memory, and network resources.
 5. The computer-implemented method ofclaim 1 wherein the event detection mechanism comprises code placed in aprocessing unit to detect an associated event in the rules registry. 6.A computer-implemented method for allocating computer resources on amulti-node computer system, the method comprising the steps of:monitoring events in a first processing unit with an event detectionmechanism comprising code placed in the first processing unit to detectan associated event in a rules registry, wherein the rules registryincludes data event rules and code point rules; analyzing input dataused by the first processing unit to determine if a data event in thefirst processing unit meets an event criteria in the rules registry;notifying a resource controller when the data event in the firstprocessing unit, corresponding to a data event rule in the rulesregistry, meets the event criteria; notifying the resource controllerwhen a code point event, corresponding to a code point rule in the rulesregistry, occurs in the first processing unit; and the resourcecontroller reallocating compute resources for a second processing unitand a third processing unit when the code point event occurs in thefirst processing unit or when the data event in the first processingunit meets the event criteria, wherein the second processing unit islocated on a compute node downstream from the first processing unit in adistributed system and the third processing unit is located on a computenode upstream from the first processing unit, and wherein, upon theresource controller receiving notification of the code point eventoccurring in the first processing unit, or upon the resource controllerreceiving notification of the data event in the first processing unitmeeting the event criteria, the resource controller reallocates thecompute resources by increasing compute resources for the secondprocessing unit and decreasing compute resources for the thirdprocessing unit, the reallocating comprising the steps of: looking up anaction in the rules registry for an event corresponding to a receivednotification; determining an affected processing unit from the rulesregistry; looking up a node hosting the affected processing unit; andreallocating resources on the node hosting the affected processing unitper actions indicated in the rules registry; wherein the computeresources for the second processing unit and the third processing unitcomprise a computer processing unit, memory, and network resources; andwherein the rules registry lists actions and events that include thefollowing: increase processing unit resources upon detection of aquantity of input data; decrease processing unit resources upondetection of a quantity of input data; increase processing unitresources upon detection of a specific type of data; decrease processingunit resources upon detection of a specific type of data; increasecomputer processing unit resources upon detection of a code point in aprocessing unit; and decrease computer processing unit resources upondetection of a code point in a processing unit.